Rights management (RM) and enforcement is highly desirable in connection with digital content such as digital audio, digital video, digital text, digital data, digital multimedia, etc., where such digital content is to be distributed to one or more users. Digital content could be static, such as a text document, for example, or it could be streamed, such as the streamed audio/video of a live event. Typical modes of distribution include tangible devices such as a magnetic (floppy) disk, a magnetic tape, an optical (compact) disk (CD), etc., and intangible media such as an electronic bulletin board, an electronic network, the Internet, etc. Upon being received by the user, such user renders the digital content with the aid of appropriate rendering software such as an audio player, a text displayer, etc. on a personal computer or other hardware.
In one scenario, a content owner or rights-owner such as an author, a publisher, a broadcaster, etc., wishes to distribute such digital content to each of many users or recipients in exchange for a license fee or some other consideration. In such scenario, then, the content may be an audio recording, a multimedia presentation, etc., and the purpose of the distribution is to generate the license fee. Such content owner, given the choice, would likely wish to restrict what the user can do with such distributed digital content. For example, the content owner would like to restrict the user from copying and re-distributing such content to a second user, at least in a manner that denies the content owner a license fee from such second user.
In addition, the content owner may wish to provide the user with the flexibility to purchase different types of use licenses at different license fees, while at the same time holding the user to the terms of whatever type of license is in fact purchased. For example, the content owner may wish to allow distributed digital content to be rendered only a limited number of times, only for a certain total time, only on a certain type of machine, only on a certain type of rendering platform, only by a certain type of user, etc.
In another scenario, a content developer, such as an employee in or member of an organization, wishes to distribute such digital content to one or more other employees or members in the organization or to other individuals outside the organization, but would like to keep others from rendering the content. Here, the distribution of the content is more akin to organization-based content sharing in a confidential or restricted manner, as opposed to broad-based distribution in exchange for a license fee or some other consideration.
In such scenario, then, the content may be a document presentation, spreadsheet, database, email, or the like, such as may be exchanged within an office setting, and the content developer may wish to ensure that the content stays within the organization or office setting and is not rendered by non-authorized individuals, such as for example competitors or adversaries. Again, such content developer wishes to restrict what a recipient can do with such distributed digital content. For example, the content owner would like to restrict the user from copying and re-distributing such content to a second user, at least in a manner that exposes the content outside the bounds of individuals who should be allowed to render the content.
In addition, the content developer may wish to provide various recipients with different levels of rendering rights. For example, the content developer may wish to allow protected digital content to be viewable and not printable with respect to one class of individual, and viewable and printable with respect to another class of individual.
However, and in either scenario, after distribution has occurred, such content owner/developer has very little if any control over the digital content. This is especially problematic in view of the fact that practically every personal computer includes the software and hardware necessary to make an exact digital copy of such digital content, and to download such exact digital copy to a write-able magnetic or optical disk, or to send such exact digital copy over a network such as the Internet to any destination.
Of course, as part of a transaction wherein the content is distributed, the content owner/developer may require the user/recipient of the digital content to promise not to re-distribute such digital content in an unwelcome manner. However, such a promise is easily made and easily broken. A content owner/developer may attempt to prevent such re-distribution through any of several known security devices, usually involving encryption and decryption. However, there is likely very little that prevents a mildly determined user from decrypting encrypted digital content, saving such digital content in an un-encrypted form, and then re-distributing same.
RM and enforcement architectures and methods have thus been provided to allow the controlled rendering of arbitrary forms of digital content, where such control is flexible and definable by the content owner/developer of such digital content. Examples of such architectures are set forth in the related applications set forth above, among, others. Such architectures allow and facilitate such controlled rendering, especially in an office or organization environment or the like where documents are to be shared amongst a defined group of individuals or classes of individuals.
As may be appreciated, central to any RM architecture is one or more applications that produce, consume, or otherwise employ (hereinafter ‘employ’) rights managed (RM) content. For example, if the RM content is a word processing document, such document may be created by a first word processing application and/or may be consumed by such first word processing application or a second word processing application. Likewise, if the RM content is a multimedia presentation, such presentation may be created by a first presentation application and/or may be consumed by such first presentation application or a second present application.
Each application that employs RM content typically includes or has local access to a RM module or the like, where the RM module performs RM functions on behalf of the application. Typically, the RM functions performed by the RM module include both functions necessary to deal with RM content and functions necessary to ensure that the application and the environment surrounding the application can be trusted to properly handle the RM content.
In the latter case in particular, the RM module may include functionality necessary to ensure that the application is not being monitored by an external element in an attempt to obtain RM content in an unprotected or ‘naked’ form. Alternatively, the application may be running on a computer as an isolated process to ensure that the application is not being monitored by such an external element. In either case, such external element may be any of several devices, but it has become apparent that a debugger may be employed by a nefarious entity as such an external element.
As should be appreciated, a debugger is a software and/or hardware device that may be set up in connection with an application during development and/or operation thereof, primarily to assist in identifying and solving problems associated with such application. Thus, the debugger includes functionality to monitor an application, to step through the application, to set or alter breakpoints associated with the application, to modify aspects of the application, and the like. Perhaps most significantly, such a debugger can read memory associated with an application, such as memory with the naked content. A nefarious entity employing such a debugger, then, can copy the naked content from the memory without any of the RM protection associated therewith.
An application that employs RM content, then, should not normally be allowed have access to such RM content if a debugger or other external element is monitoring the application. Otherwise, and as set forth above, the debugger can be employed to copy the RM content in a naked form. Accordingly, the RM module typically attempts to detect any such debugger, and if such a debugger is detected the RM module takes appropriate action such as shutting down the application and/or refusing to allow the application to have access to RM content.
An issue arises, however, in that certain instances exist wherein a debugger nevertheless should be allowed to monitor an application that has access to RM content. Most prominently, such certain instances include the instance where the developer of the application is in fact developing and/or debugging the application and as part of such development/debugging legitimately requires use of a debugger. Of course, other similar instances exist. As should be appreciated, though, despite the legitimate need for using a debugger with the application, the RM module associated with the application upon detecting such debugger will take the aforementioned appropriate action and thereby in fact prevent the legitimately debugging application from having access to RM content.
A need exists, then, for a method and mechanism that allows use of a debugger with an application that employs RM content. In particular, a need exists for such a method and mechanism whereby a developer of the application or the like with a legitimate need can debug the application. Even more particularly, a need exists for such a method and mechanism whereby such developer or the like can run the application with the RM module, where the RM module is part of an isolated process but the application is not part of an isolated process. As such a debugger can monitor the application but not the RM module.